Add LoongArch support for kpatch v2 #1427

georgejguo · 2024-12-05T08:28:32Z

hi joe,
This pr is based for PR #1415.

jpoimboe · 2024-12-05T19:05:32Z

@georgejguo FYI, instead of opening a new PR, next time you can just rebase your existing branch and force push it, which will reuse the existing PR.

joe-lawrence

Hi @georgejguo - this is a really quick scan of the v2 patchset, see the github comments inline. A few follow ups:

Are there LoongArch specific objects files that are generated by the kernel build, but aren't really part of the kernel itself? See kpatch-build/kpatch-cc and the long list of fileglobs that the are skipped. For example, I'd expect to see arch/loongarch/vdso/* in there.
Without hardware, this will be difficult for us to test and maintain. Are there any public LoongArch resources available for running integration tests?
Do the integration tests run for your kernel? (Which one(s) btw?)
Would you be willing to generate a set of unit test object files (see https://github.com/dynup/kpatch-unit-test-objs where we keep those for various arches. I can walk you through how to generate them.)
Last but not least, @jpoimboe what are your thoughts on supporting arches (arm64 and now LoongArch) that require out-of-tree kernel patches? I was leaning towards some kind of disclaimer and a very careful check that the kernel matches one of these special downstream versions.

joe-lawrence · 2024-12-05T17:42:21Z

kpatch-build/create-diff-object.c

 		break;

+	case LOONGARCH64:
+		/* to be done */


I m not sure here, so just commit "to be done". Actually it can pass my simple test case.

joe-lawrence · 2024-12-05T17:51:06Z

kpatch-build/create-diff-object.c

+			bool found = false;
+			unsigned int *insn = sym->sec->data->d_buf + sym->sym.st_value;
+
+			if (*insn == LOONGARCH_NOP && *(insn + 1) == LOONGARCH_NOP)


I do not believe this is endian-safe, ie, if this were run on a BE system like s390x (hypothetical/future cross compilation case), then the bytes would not be in the expected order. See other arch cases or https://github.com/dynup/kpatch/pull/52863dace0200332dc2ed5d8edab1f017e63b368 for specific bugfix where insn is treated as a sequence of bytes and not an unsigned integer.

the link(https://github.com/dynup/kpatch/pull/52863dace0200332dc2ed5d8edab1f017e63b368) is 404 error

Sorry about that, try this link: 52863da for ("create-diff-object: fix endianness in kpatch_no_sibling_calls_ppc64le()")

kpatch-build/create-diff-object.c

joe-lawrence · 2024-12-05T20:16:56Z

kpatch-build/kpatch-elf.c

+				rela->sym = rela->sym->sec->secsym;
+				log_debug("section symbol: %s\n", rela->sym->name);
+			}
+		}


Just curious, which kernel source files are generating these symbols?

Okey, I will try to find it.

joe-lawrence · 2024-12-05T20:40:18Z

kpatch-build/create-diff-object.c

 				sym->has_func_profiling = 1;
 			break;
+		case LOONGARCH64:
+			struct section *sec;


Older gcc complains about this:

gcc -std=gnu11 -MMD -MP -I../kmod/patch -Iinsn -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -g -Werror -c -o create-diff-object.o create-diff-object.c create-diff-object.c: In function ‘kpatch_find_func_profiling_calls’: create-diff-object.c:4106:4: error: a label can only be part of a statement and a declaration is not a statement struct section *sec; ^~~~~~

if this new variable remains in v3, please wrap the case block in {} brackets to appease those compilers.

georgejguo · 2024-12-06T09:07:13Z

Hi @georgejguo - this is a really quick scan of the v2 patchset, see the github comments inline. A few follow ups:

Are there LoongArch specific objects files that are generated by the kernel build, but aren't really part of the kernel itself? See kpatch-build/kpatch-cc and the long list of fileglobs that the are skipped. For example, I'd expect to see arch/loongarch/vdso/* in there.

Okey, I will clear it out and try to find ones if it turns out to be ture.
Could you give me some help, I don't know how to find these files?
BTW, this is related my kpatch-elf.c patch?

Without hardware, this will be difficult for us to test and maintain. Are there any public LoongArch resources available for running integration tests?

Do the integration tests run for your kernel? (Which one(s) btw?)

I have tested the code in Fedora-38 with kernel 6.12 and gcc 14.1 for Loongarch, just a simple cases.
As far as I know, there is not any public LoongArch machines availabe for testing, But I have enough machines, and I am willing to maintain and test.

Would you be willing to generate a set of unit test object files (see https://github.com/dynup/kpatch-unit-test-objs where we keep those for various arches. I can walk you through how to generate them.)

Yeap, I am willing to do that.

Last but not least, @jpoimboe what are your thoughts on supporting arches (arm64 and now LoongArch) that require out-of-tree kernel patches? I was leaning towards some kind of disclaimer and a very careful check that the kernel matches one of these special downstream versions.

The kernel has supported liveptch for Loongarch in upstream.

[edited by Joe to cleanup the markdown for github web rendering]

joe-lawrence · 2024-12-06T14:43:30Z

The kernel has supported liveptch for Loongarch in upstream.

Great, thanks for heads up. I must have missed it as it seems like the patchset to turn on the config for that arch was never copied to the live-patching@vger.kernel.org mailing list (actually having some problems finding much lmkl discussion / posts, too). Anyway select HAVE_LIVEPATCH is indeed present in arch/arloongarch/Kconfig.

joe-lawrence · 2024-12-10T17:00:25Z

Are there LoongArch specific objects files that are generated by the kernel build, but aren't really part of the kernel itself? See kpatch-build/kpatch-cc and the long list of fileglobs that the are skipped. For example, I'd expect to see arch/loongarch/vdso/* in there.

Okey, I will clear it out and try to find ones if it turns out to be ture.
Could you give me some help, I don't know how to find these files?

Hmm, I don't know of a programmatic way off the top of my head, maybe @jpoimboe has a suggestion. That said, the vdso code should be excluded for sure.

BTW, this is related my kpatch-elf.c patch?

Sort of. Using a gcc-14.2.0 cross compiler and the latest kernel tree, I couldn't find any .LBB symbol instances outside of the vdso object files... that's why I was curious to know if it is something that create-diff-object really needs to account for (if the pattern never occurs in kernel code).

georgejguo · 2024-12-11T03:06:15Z

hi， this is Add LoongArch support for kpatch v3

The updated file is only kpatch-build/create-diff-object.c according to your advice, Joe
The commit id is f27619f

joe-lawrence · 2024-12-12T22:07:01Z

Hi @georgejguo , I tried this branch's version of create-diff-object against object files created by a gcc-14.2.0 cross compiler and the examples/cmdline.patch, but encountered this error, "changed section .rela.orc_unwind_ip not selected for inclusion". Then I found this stale PR: #1312 where @ZhangHongchen1 mentioned that section with regard to arch-specific differences on LoongArch.

I also noticed that he has a detailed LoongArch support branch in his fork that accounts for several additional things, like trampolines for short (local?) function calls, load immediate instructions, etc. It would be worth seeing if @ZhangHongchen1 intends to pick up or continue that work and then combine efforts with a single PR.

georgejguo · 2024-12-13T01:53:38Z

hi， this is Add LoongArch support for kpatch v4

The updated file is only kpatch-build/create-diff-object.c
The commit id is 695b74b which fixes error, "changed section .rela.orc_unwind_ip not selected for inclusion".

I also added Co-developed-by: zhanghongchen zhanghongchen@loongson.cn.

Sorry, I lost this commit while pushing ”Add LoongArch support for kpatch V3“

georgejguo · 2024-12-13T02:06:37Z

Hi @georgejguo , I tried this branch's version of create-diff-object against object files created by a gcc-14.2.0 cross compiler and the examples/cmdline.patch, but encountered this error, "changed section .rela.orc_unwind_ip not selected for inclusion". Then I found this stale PR: #1312 where @ZhangHongchen1 mentioned that section with regard to arch-specific differences on LoongArch.

I also noticed that he has a detailed LoongArch support branch in his fork that accounts for several additional things, like trampolines for short (local?) function calls, load immediate instructions, etc. It would be worth seeing if @ZhangHongchen1 intends to pick up or continue that work and then combine efforts with a single PR.

Sorry, I lost a commit to fix this while pushing ”Add LoongArch support for kpatch V3“.
Actually , In my test case, everything is OK, except for section .rela.orc_unwind_ip.
If there are other sections like '.rela.orc_unwind_ip', it would be better to open a new PR for them."
@ZhangHongchen1 what's your opinion, Hongchen?

georgejguo · 2024-12-13T03:46:50Z

hi， this is Add LoongArch support for kpatch v5

The updated file is only kpatch-build/create-diff-object.c
The commit id is dcf1188 fixing error, "changed section .rela.orc_unwind_ip not selected for inclusion", which is better than v4 695b74b)

georgejguo · 2025-01-22T03:04:53Z

hi，Joe
I added arch/loongarch/vdso to kpatch-build/kpatch-cc.
Thanks for your advice.

github-actions · 2025-05-16T10:23:46Z

This PR has been open for 60 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

github-actions · 2025-07-22T10:26:54Z

This PR has been open for 60 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

Add section alt_instr check support for LoongArch. Signed-off-by: George Guo <guodongtai@kylinos.cn>

georgejguo · 2025-09-26T03:49:10Z

hi Joe，

the fail log below：

run make unit
make -C kpatch-build
make[1]: Entering directory '/home/runner/work/kpatch/kpatch/kpatch-build'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/runner/work/kpatch/kpatch/kpatch-build'
make -C test/unit
make[1]: Entering directory '/home/runner/work/kpatch/kpatch/test/unit'
make -C objs/aarch64
make[2]: Entering directory '/home/runner/work/kpatch/kpatch/test/unit/objs/aarch64'
BUILD cmdline-patch
create-diff-object: ERROR: cmdline-patch.ORIG.o: kpatch_bundle_symbols: 318: symbol cmdline_proc_show at offset 8 within section .text.cmdline_proc_show, expected 0
make[2]: *** [../../Makefile.include:60: cmdline-patch.OUTPUT.o] Error 1
make[2]: Leaving directory '/home/runner/work/kpatch/kpatch/test/unit/objs/aarch64'
make[1]: *** [Makefile:14: aarch64-test] Error 2
make[1]: Leaving directory '/home/runner/work/kpatch/kpatch/test/unit'
make: *** [Makefile:42: unit] Error 2
Error: Process completed with exit code 2.

Could you explain the test environment setup and how to run the unit tests?
I want to know the unit test OS version.
So I can build it locally, testing by myself, then push the code. @joe-lawrence

joe-lawrence · 2025-10-13T13:53:34Z

Hi @georgejguo :

The test/unit/objs is a submodule reference to https://github.com/dynup/kpatch-unit-test-objs. You should be able to initialize / update it locally with a git cmd like: git submodule update --init --recursive. From there, make unit will run across those files.

If you are going to create your own unit tests, it may just be easier to debug by replacing that objs directory with a set of your own files (adjust the arches accordingly) rather than messing with git submodules for the time being.

The arch object file directory contains file sets:

.env - set environment variables for the test (i.e. JUMP_STRUCT_SIZE=16)
.ORIG.o - a reference kernel build object (get this from ~/.kpatch/tmp/orig/...)
.PATCHED.o - a patched kernel build object (get this from ~/.kpatch/tmp/patched/... )
.test - a bash script to verify that a test-generated .OUTPUT.o was created correctly. Current tests may check for ELF properties, or simply the number of patched functions extracted

Each object file should be stripped with strip --strip-debug --keep-file-symbols --remove-section=.eh_frame.

You may use https://github.com/dynup/kpatch-unit-test-objs/pull/54/files as a template. You can use some of the integration test object files, but anything that is arch-specific will be most interesting.

joe-lawrence · 2025-10-13T14:06:34Z

make -C objs/aarch64
make[2]: Entering directory '/home/runner/work/kpatch/kpatch/test/unit/objs/aarch64'
BUILD cmdline-patch
create-diff-object: ERROR: cmdline-patch.ORIG.o: kpatch_bundle_symbols: 318: symbol cmdline_proc_show at offset 8 within section .text.cmdline_proc_show, expected 0

This suggests that the branch broke the aarch64 kpatch code.

From the test's object file, the expected offset is 8 bytes and not 0 as the error describes:

$ aarch64-linux-gnu-objdump -Dr -j.text.cmdline_proc_show objs/aarch64/cmdline-patch.ORIG.o
...
Disassembly of section .text.cmdline_proc_show:

0000000000000000 <cmdline_proc_show-0x8>:
   0:   d503201f        nop
   4:   d503201f        nop

0000000000000008 <cmdline_proc_show>:
   8:   d503201f        nop
   c:   d503201f        nop

Any LoongArch-specific assumption about the function symbol vs. section beginning should be wrapped up in an arch-specific case.

Add initial support for LoongArch. Signed-off-by: George Guo <guodongtai@kylinos.cn>

Generate 2 NOPs right at the beginning of each function with -fpatchable-function-entry=2 in LoongArch. Here process this situation. Co-developed-by: zhanghongchen <zhanghongchen@loongson.cn> Signed-off-by: zhanghongchen <zhanghongchen@loongson.cn> Signed-off-by: George Guo <guodongtai@kylinos.cn>

Here fix error like: "tcp.o: symbol changed sections: .LBB7266. create-diff-object: unreconcilable difference". Due to LoongArch GCC generating local labels such as .LBB7266, it is difficult to compare the modified sections in the corresponding object files of the two files before and after the patch, so change them with sections symbols in rela section, and delete them in other sections. Co-developed-by: zhanghongchen <zhanghongchen@loongson.cn> Signed-off-by: zhanghongchen <zhanghongchen@loongson.cn> Signed-off-by: George Guo <guodongtai@kylinos.cn>

Fix error: "changed section .rela.orc_unwind_ip not selected for inclusion". This section is about arch-specific differences on LoongArch, which is generated by LoongArch gcc. Signed-off-by: George Guo <guodongtai@kylinos.cn>

Since kpatch now supports LoongArch basically, enable the build. Signed-off-by: George Guo <guodongtai@kylinos.cn>

Added conditional compilation to prevent 'R_LARCH_64' and 'EM_LOONGARCH' from being referenced on x86 and other non-LoongArch architectures. This ensures the code works across different architectures without errors. Signed-off-by: George Guo <guodongtai@kylinos.cn>

Add arch/loongarch/vdso to the list of object files that kpatch-cc won't add to its changed_objs list. Signed-off-by: George Guo <guodongtai@kylinos.cn>

… kernel panic On LoongArch systems, livepatch modules containing references to EXTERNAL global variables trigger kernel panics when the core kernel is built with -mdirect-extern-access optimization. Root cause: The -mdirect-extern-access optimization replaces GOT-based external symbol access with direct addressing for improved performance. However, this breaks the kernel module loading mechanism which relies on GOT entries for proper relocation of EXTERNAL symbol references. Direct access to global variables from livepatch modules causes invalid memory accesses and kernel panics. Solution: For LoongArch kpatch builds, conditionally disable direct-extern-access by adding: - -mno-direct-extern-access for GCC builds - -fno-direct-access-external-data for Clang builds Signed-off-by: George Guo <guodongtai@kylinos.cn>

…it symbol references Add architecture-specific -fPIC compiler flag for LoongArch64 to prevent kernel panics when applying livepatches containing references to symbols defined in the same compilation unit. Root cause: In the kpatch workflow, when a function is livepatched, it's extracted from the original object file and compiled into a separate kernel module. When the patched function references symbols defined in the same compilation unit (like 'uts_sem' in kernel/sys.c), these references break if not compiled as position-independent code. On LoongArch64, without -fPIC, references to same-compilation-unit symbols use absolute addressing that assumes fixed memory locations. When the function is relocated into the livepatch module, these absolute addresses become invalid, causing kernel panics. Example failure case: - SYSCALL_DEFINE1(newuname) references the same-compilation-unit symbol 'uts_sem' - When kpatch extracts this function into a module, the reference to 'uts_sem' must be properly relocated - Without -fPIC, the absolute address reference causes invalid memory access and kernel panic Solution: Force -fPIC compilation for all LoongArch64 kpatch builds. This ensures that references to same-compilation-unit symbols use position-independent addressing, allowing proper relocation by the kernel module loader and preventing kernel panics in livepatch scenarios. Co-developed-by: Kexin Liu <liukexin@kylinos.cn> Singed-off-by: Kexin Liu <liukexin@kylinos.cn> Signed-off-by: George Guo <guodongtai@kylinos.cn>

joe-lawrence reviewed Dec 5, 2024

View reviewed changes

georgejguo force-pushed the master branch from a873bfa to 0f0c129 Compare December 11, 2024 02:59

georgejguo force-pushed the master branch from 0f0c129 to b49793e Compare December 13, 2024 01:49

georgejguo force-pushed the master branch from b49793e to 31b8eb5 Compare December 13, 2024 03:40

georgejguo force-pushed the master branch from 597f94d to 5b329c7 Compare March 17, 2025 01:52

github-actions bot added the stale label May 16, 2025

github-actions bot removed the stale label May 23, 2025

github-actions bot added stale and removed stale labels Jul 22, 2025

georgejguo force-pushed the master branch 3 times, most recently from 1eb2f02 to 79b4354 Compare September 23, 2025 03:40

kpatch/LoongArch: Add LoongArch specific features

2e0551d

Add section alt_instr check support for LoongArch. Signed-off-by: George Guo <guodongtai@kylinos.cn>

georgejguo force-pushed the master branch from 79b4354 to 08fe5c6 Compare September 25, 2025 07:20

kpatch/LoongArch: Add initial support for kpatch

4835b29

Add initial support for LoongArch. Signed-off-by: George Guo <guodongtai@kylinos.cn>

georgejguo added 6 commits October 27, 2025 18:01

kpatch/LoongArch: skip section .rela.orc_unwind_ip

018676a

Fix error: "changed section .rela.orc_unwind_ip not selected for inclusion". This section is about arch-specific differences on LoongArch, which is generated by LoongArch gcc. Signed-off-by: George Guo <guodongtai@kylinos.cn>

kpatch/LoongArch: enable kpatch build

c568de1

Since kpatch now supports LoongArch basically, enable the build. Signed-off-by: George Guo <guodongtai@kylinos.cn>

kpatch/LoongArch: ignore arch/loongarch/vdso

eab48a0

Add arch/loongarch/vdso to the list of object files that kpatch-cc won't add to its changed_objs list. Signed-off-by: George Guo <guodongtai@kylinos.cn>

georgejguo force-pushed the master branch 3 times, most recently from e4770a6 to 1a99e6c Compare October 28, 2025 01:51

georgejguo and others added 2 commits November 18, 2025 10:06

georgejguo force-pushed the master branch from 1a99e6c to 3d44f1b Compare November 18, 2025 02:49

Add LoongArch support for kpatch v2 #1427

Are you sure you want to change the base?

Add LoongArch support for kpatch v2 #1427

Conversation

georgejguo commented Dec 5, 2024

Uh oh!

jpoimboe commented Dec 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joe-lawrence left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

georgejguo commented Dec 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joe-lawrence commented Dec 6, 2024

Uh oh!

joe-lawrence commented Dec 10, 2024

Uh oh!

georgejguo commented Dec 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joe-lawrence commented Dec 12, 2024

Uh oh!

georgejguo commented Dec 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

georgejguo commented Dec 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

georgejguo commented Dec 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

georgejguo commented Jan 22, 2025

Uh oh!

github-actions bot commented May 16, 2025

Uh oh!

github-actions bot commented Jul 22, 2025

Uh oh!

georgejguo commented Sep 26, 2025

Uh oh!

joe-lawrence commented Oct 13, 2025

Uh oh!

joe-lawrence commented Oct 13, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jpoimboe commented Dec 5, 2024 •

edited

Loading

georgejguo commented Dec 6, 2024 •

edited

Loading

georgejguo commented Dec 11, 2024 •

edited

Loading

georgejguo commented Dec 13, 2024 •

edited

Loading

georgejguo commented Dec 13, 2024 •

edited

Loading

georgejguo commented Dec 13, 2024 •

edited

Loading